【レポート】「ガンホー、データセンタークロージングへ！」AWS Summit Tokyo 2019 #AWSSummit

毎日ラグナロクオンラインをプレイしている私得なガンホーさんのセッションです！！！ AWS Summit Tokyo 2019のセッションレポートです。こちらでは「ガンホー、データセンタークロージングへ！」の内容をレポートします。

AWS Summit Tokyo 2019

#AWS

#イベントレポート

臼田佳祐

2019.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さん、ラグナロクオンラインをプレイしていますか？私は毎日プレイしています。

最近では生体研究所に関するエピソードのアップデートがあり面白い展開になっています。

「昔プレイしていたなー」という方も「やったこと無いけど気になっていた」という方も、今ならリスタートガイドで再開しやすかったり、スペシャル利用券でサクッと高レベルに追いつけたり、人だけではなく猫のキャラクターで無料で始めたりできるのでぜひプレイしていただきたいです！(個人的な活動)

ちなみに最近スマホアプリでラグナロクマスターズがリリースされましたので、スマホでも楽しめますよ！！

前置きはさておき、こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

本ブログでは『ガンホー、データセンタークロージングへ！』に関する内容をレポートしたいと思います。

AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

ガンホー・オンライン・エンターテイメント株式会社 CTO

菊池貴則

【仮】2002年から続くラグナロクオンラインを昨年AWSへ完全移行。さらに、年内にデータセンタークロージングに向けた取り組みについてお話しいたします。

レポート

世界中の人々にエンターテインメントを通じて「感動と楽しい経験」を提供する
パズトラやラグナロクオンラインを提供
直近ではラグナロクマスターズを提供
今日のお品書き
- 現在までのインフラ環境
- データセンタークロージングの背景
- クロージングに向けての取り組み
- ラグナロクオンライン移行
- その他のシステム移行
- ハマったところ
- 移行後の良かったところ
現在までのインフラ環境
- PCオンラインゲームでは2002-2008にラグナロクオンラインなどタイトル増加でサーバが増えていた
- 2010-2013で仮想化導入で物理サーバを最小限に抑える
- 1000台を超えていたが、インフラチームは4-5人くらい
- 2014-2016タイトルの縮小や仮想化促進で58%ぐらいまで縮小
- 2017-2019仮想化効率をあげて2013年と比較して12%程度
- 2019年末データセンター契約終了をしてAWS完全移行
経緯
- 複数契約していたデータセンター統合
- 数カ月後にデータセンター閉鎖の通知を受ける
  - 想定外だった
- 新しいデータセンターを契約するかとか検討したが、完全クラウド環境移行の検討を開始
クロージングに向けての取り組み
- 確認したこと
  - どこんクラウドベンダーにするの？
  - ラグナロクオンライン動くの？
    - 当時はぜんぜんわからなかった
  - コストどうなるの？
- どこにするかは当然AWSということではない
  - 比較検討してAWSにした
  - 方針としてはいいものは使っていく
  - ポイント
    - パズドラを始めとするスマホタイトルでの利用実績
    - 移行におけるサポート体制の充実(エンタープライズサポートの活用)
    - 営業やTAMと手厚くやっている
- 動くのか？
  - 動いた
  - 詳細は後ほど
- コストは？
  - シミュレーションして安くなることが判明
  - 考え方
    - 3年合計で計算
    - データセンター費用・サーバ費用だけでなく保守費やOS/ソフトウェア費用も計算
    - 実行時・未実行時を月ごとに計算
  - 長いエクセルを作成
- 全体として行けるという決断
移行
- 移行計画
  - 2017月後半からAWS環境動作検証
  - 2018月 3-4月調整
    - コストシミュレーションよりも詳細な費用算出
    - 実際のラグナロクオンライン運営チームと調整
  - 2018年3月テストサーバ検証
    - 運用チームも含めて動作確認
  - 2018年5-6月　本番系サーバ構築
  - 2018年7-8月　ワールドごと移行
    - 合計4回
    - 最初2ワールド
- 移行方法
  - P2VやV2Vツールも検討したけどすべてのサーバを新規構築した
    - メリットがあんまり感じられなかった
  - 課金システム等は別で移行
  - 課金システム等との接続の観点からデータセンターとDirectConnectを接続
    - バックアップ回線としてVPN接続
    - 思ったほど高くなかった
  - サーバ構成
    - EC2でパブリックサブネットにたくさん
    - 古いゲームで古いプログラムなのでほとんどT2で動いている
    - 負荷高いところはT3
    - RDSを使ってない
      - EC2 on SQL Server
      - M4とかを使っている
      - RDSを検討はしたが、SQL Serverのライセンスを保持していたのでBYOLで安くした
      - バージョン上がった時には再検討したい
  - 工夫した点
    - もともとNAT環境下で動くことが考慮されてないサーバプログラムだったため動作させるためにいろいろ
    - 前提
      - 各サーバのグローバルIP/プライベートIPがDBに保存されている
      - サーバプロセス内に起動時にDBに自分のIPをキーにして情報を引っ張る
      - 通信先のサーバIPを引っ張る
      - クライアントからも各サーバに各ワールドのグローバルIPを問い合わせる
      - AWS環境では3つのIPをあてられない
    - 発生した問題
      - 管理サーバは自分のIPがDBのグローバルから取得できない
      - クライアントが接続できない
      - 解決方法
        
        管理サーバ用とその他でDB分割
        
        グローバルIPに登録するIPをプライベートIPとEIPで分ける
        
        プロセス毎にDB接続先を変更
      - やっと起動！
  - サーバ移行について
    - サーバ入れ替えはAWS化以前も何度もやっていたのでそれほど大差ない
      - AMI作る
      - インスタンス起動
        
        EIP付与/プライベートIP固定
        
        サーバプログラム設置
      - DB
        
        ベースAMI作成
        
        起動してプライベートIP固定
      - シンプルで自動化しやすい
はまったところ
- 仕様把握不足でT系インスタンスのCPUクレジット枯渇
  - 管理サーバとZoneサーバが通信できないとZone障害が発生する
  - CPUクレジットバランス0になると通信ができなくなる
  - Zoneサーバ障害が発生
  - 2回めの移行で過疎っているZoneで起きてしまった
  - T2/T3 Unlimitedへ変更
- ホスト障害の問題
  - StatusCheckFailedが一回だけ発生して復旧することがあった
  - ゲームは動作しなくなる
  - CloudWatchベースで監視していて気づきづらかった
  - StatusCheckFailedが出たらすぐにSlack通知するようにし状況確認した
  - 後ほど自動化した
その他システム移行
- DNSをRoute53に
- MailをSESに
- バッチをBatch Lambdaへ
- 一部WebをLightSail
- 一部APIをAPI Gateway + Lambda
移行の良かった点
- サーバ監視ソフトが無くなる(予定)
- サーバパッチ配布が楽になった
- コストが下がった
  - 3年合計で-10%
  - 4年目以降-55%
- オンプレしか触ってきてなかったメンバーの知識・スキルが向上した！
  - 新しい提案がメンバーから出るようになった
まとめ
- 3年かけて移行を行っているが、ラグナロクオンラインについては想定よりも遥かに簡単に移行することができた
- 現状大きなトラブルもなく安定稼働している
- その他システムも問題なさそう
- コストも当然ながら、自動化も加速している
おまけ
- ほかサービスのアーキテクチャ
- コンテナを使っている
- GPS系だけ通常のAPIと分けている
- GPS側はSQSでためてworkerでAuroraに書き込んでいる
- コンテナのログはCloudWatch Logsに送るのが基本構成
- Dnsmasqを使うのはほぼ必須
  - Auroraの限界を迎えることがあった
エンジニア積極採用中です！